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REAL PARTY IN INTEREST 

The real party in interest is Sharp Laboratories of America, 
Inc., as assignee of the parent application in the United States Patent 
Office, with a recordation date of February 5, 2004, at Reel 014969, Frame 
0605. 

RELATED APPEALS AND INTERFERENCES 

None. 

STATUS OF THE CLAIMS 

Claims 5-6, 9-10, 16-17, 20-21, 26-27, 29-30, 36-37, and 39-40 

are canceled. 

Claims 1-4, 7-8, 11-15, 18-19, 22-25, 28, 31-35, 38, and 41-44 
are in the application. 

Claims 1-4, 7-8, 11-15, 18-19, 22-25, 28, 31-35, 38, and 41-44 

are rejected. 

Claims 1-4, 7-8, 11-15, 18-19, 22-25, 28, 31-35, 38, and 41-44 

are appealed, 

STATUS OF AMENDMENTS 

Amendments to the claims were presented in a paper received 
at the PTO on October 7, 2008. These claim amendments have been 
entered. 
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SUMMARY OF CLAIMED SUBJECT MATTER 



The motion pictures expert group (MPEG)-2 standard 
requires that a receiver remain synchronized to a broadcasting device. 
Synchronization is accomplished through the use of a master clock in the 
broadcasting device and a slave clock in the receiver. The broadcasting 
device sends program clock reference (PCR) timestamps in the MPEG2 
transport stream (TS) for the purpose of correcting the slave clock in the 
receiver. As long as the receiver slave clock is accurate, jitter in the 
transmission can be tolerated (specification: page 1, In. 11 through page 2, 
In. 11, see Figs. 10 and 11). An MPEG2 TS is comprised of packets, where 
each packet includes a header and a payload (Fig. 12). The PCR 
timestamp is inserted into header of a packet at the interval of at least 
once per 100ms (i.e. not every packet header includes a PCR time stamp). 
The timestamps maintain clock synchronization, and clock 
synchronization guarantees that the MPEG2 images are displayed at the 
correct time. 

An MPEG2 TS may be carried in a higher level real-time 
protocol (RTP) Internet protocol (IP) packet, which is also comprised of 
header and payload sections. That is, several MPEG2 packets may be 
carried in the payload of an IP packet (Fig. 13). The RTP IP packet 
header carries a low resolution RTP timestamp. However, since IP 
packets need not be transmitted per a schedule, the delay introduced 
through the IP network cannot be known by the MPEG2 receiver. To 
address this problem the claimed invention creates a linkage between the 
RTP timestamp and the PCR timestamp. Then, the RTP timestamp, 
through its linkage to the more precise PCR timestamp, can be used to 
represent the MPEG2 packet target transmission time. In other words, 



SLAI535_appeai brief.doc 



4 



the delay through the IP network can be calculated since the MPEG 
network target transmission is known. Advantageously, the claimed 
invention creates the linkage between timestamps regardless of the 
position of the PCR MPEG2TS packet inside the IP packet payload. 

Claim 1 recites a method for receiving an MPEG2 transport 
stream (TS) in a real-time protocol (RTP)/user datagram protocol 
(UDP)/Internet protocol (IP) packet (specification: page 13, In. 3 through 
page 14, In. 7, Fig. 8). Step 802 receives an IP packet via an IP network, 
having a variable transmission delay (page 13, In. 3-4). Step 804 accesses 
a timestamp carried in a RTP packet; (page 13, In: 4-5). Step 805 accesses 
an index field in the RTP packet header (page 14, In. 3-4). Step 806 links 
the timestamp with a program clock reference (PCR) MPEG2TS carried in 
the RTP packet payload by using the index to point to a PCR MPEG2TS 
randomly positioned in the RTP packet payload (page 13, In. 5-6 and page 
14, In. 4-7). Step 808 uses the timestamp to eliminate variable 
transmission delay jitter, associated with the PCR MPEG2TS (page 13, In. 
6-8). 

Claim 12 recites a method for transmitting an MPEG2TS in 
a RTP)/UDP/IP packet (specification, page 15, In. 5 through page 16, In. 3, 
Fig. 9). Step 902 encapsulates a program clock reference (PCR) 
MPEG2TS in the RTP packet payload (page 15, In. 7-8). Step 904 
encapsulates a timestamp randomly positioned in a RTP packet payload, 
referencing the PCR MPEG2TS target transmission time. Step 906 
encapsulates the RTP packet in an IP packet (page 15, In. 10). Step 905 
encapsulates an index in the RTP packet header pointing to the position 
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of the MPEG2TS in the RTP packet payload (page 16, In. 1-3). Step 908 
transmits the IP packet via an IP network (page 15, In. 10-11). 

Claim 22 recites a system for receiving an MPEG2TS in an 
RTP/UDP/IP packet (specification: page 6, In. 10 through page 7, In. 7, 
page 8, In. 15-24, Figs. 1, 10, 11, and 4). A decoder, referred to as a 
system decoder in Fig. 11 or receiver 102 in Fig. 1, has an IP network 
interface to receive an IP packet via an IP network, having a variable 
transmission delay. The decoder has an interface to supply a RTP packet 
(page 6, In. 10-19). A buffer (Fig. 11), referred to as a de-jitter module 108 
in Fig. 1, has an interface to accept the RTP packet. The buffer accesses a 
timestamp packet index field carried in a RTP packet header (page 6, In. 
20-22), and uses the timestamp packet index to point to a PCR MPEG2TS 
randomly positioned in the RTP packet payload (page 8, In. 15-24, see Fig. 
4). The buffer links the timestamp with a PCR MPEG2TS carried in the 
RTP packet payload, and uses the timestamp to eliminate variable 
transmission delay jitter. The buffer has an interface to supply the PCR 
MPEG2TS with a constant delay (page 6, In. 22 through page 7, In. 2). A 
system clock (see Fig. 10), referred to as the de-jitter module in Fig. 1, has 
an interface to receive the PCR MPEG2TS with the constant delay and to 
provide a synchronized system time. 

Claim 32 recites a system for transmitting an MPEG2TS in a 
RTP/UDP/IP packet (specification: page 10, In. 24 through page 11, In. 9, 
page 11, In. 21-25, Figs. 4, 7, 10, 11). The system comprises a system 
clock (see Fig. 10), which is part of the encapsulation module 702 of Fig. 7, 
having an interface to supply a program clock reference (PCR) MPEG2TS. 
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A buffer (Fig. 11), which is part of the encapsulation module of Fig. 7, has 
an interface to accept the PCR MPEG2TS (page 10, In. 25 through page 
11, In. 1). The buffer randomly positions the PCR MPEG2TS in a RTP 
packet payload (page 11, In. 21-25, Fig. 4), encapsulates a timestamp 
packet index in the RTP packet header referencing the PCR MPEG2TS 
target transmission time, and encapsulates the RTP packet in an IP 
packet. The timestamp packet index points to the position of the 
MPEG2TS in the RTP packet payload (page 11, In. 1-4). The buffer 
supplies the IP packet at an interface (page 11, In. 5-6). A system coder 
(Fig. 11), referred to as a transmitter 708 in Fig. 7, has an interface to 
accept the IP packet and an interface to transmit the IP packet via an IP 
network (page 11, In. 6-8). 

Claim 41 recites a method for receiving an MPEG2TS in an 
RTP/UDP/IP packet (specification page 13, In. 3 through page 14, In. 7, 
page 14, In. 17-23, and Figs. 6 and 8). Step 802 receives an IP packet via 
an IP network, having a variable transmission delay (page 13, In. 3-4). 
Step 804 accesses a local timestamp field in an MPEG2TS delay 
compensation data structure, where the MPEG2TS delay compensation 
data structure is carried in the RTP packet payload and includes the local 
timestamp and a corresponding PCR MPEG2TS (page 13, In. 4-5, page 14, 
In. 17-21). Step 806 links the timestamp with a program clock reference 
(PCR) MPEG2TS carried in the RTP packet payload (page 13, In. 5-6). 
Step 808 uses the timestamp to eliminate variable transmission delay 
jitter, associated with the PCR MPEG2TS (page 13, In. 6-8). In this 
aspect of the method, linking the timestamp with a PCR MPEG2TS 
carried in the RTP packet (Step 806) includes linking the local timestamp 
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to the corresponding PCR MPEG2TS in the MPEG2TS delay 
compensation data structure (page 14, In. 21-23, Fig. 6). 

Claim 43 recites a method for transmitting an MPEG2TS in 
an RTP/UDP/IP packet (specification, page 15, In. 5 through page 16, In. 
3, page 16, In. 14-20, and Figs. 6 and 9). Step 902 encapsulates a PCR 
MPEG2TS in an MPEG2TS delay compensation structure, carried in the 
RTP packet payload (page 16, In. 14-17). Step 904 encapsulates a 
timestamp in a RTP packet, referencing the PCR MPEG2TS target 
transmission time (page 15, In. 8-9). Step 906 encapsulates the RTP 
packet in an IP packet (page 15, In. 10). Step 908 transmits the IP packet 
via an IP network (page 15, In. 10-11). In this aspect encapsulating a 
timestamp in the RTP packet (Step 904) includes encapsulating a local 
timestamp in the MPEG2TS delay compensation data structure, 
referencing the co-encapsulated PCR MPEG2TS (page 16, In. 17-20, Fig. 
6). 
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GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 



1. Whether claims 1, 3-4, 7-8, 11-12, 14-15, 18-19, 22, 24- 
25, 28, 31-32, 34-35, 38, and 40-44 are anticipated under 35 U.S.C 102(e) 
by Ueda et al. ("Ueda"; US 2004/0190459). 

2. Whether claims 2, 13, 23, and 33 are unpatentable 
under 35 U.S.C. 103(a) with respect to Ueda in view of Ando et al. 
("Ando"; US 7,274,863). 
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ARGUMENT 



1. The rejection of claims 1, 3-4, 7-8, 11-12, 14-15, 18- 
19, 22, 24-25, 28, 31-32, 34-35, 38, and 40-44 under 35 U.S.C 102(e) as 
anticipated by Veda et al ("Ueda"; US 2004/0190459). 

CLAIMS 1. 12. 22. 32. 41. AND 43 

In Section 3 of the Office Action claims 1, 3-4, 7-8, 11-12, 14- 
15, 18-19, 22, 24-25, 28, 31-32, 34-35, 38, and 40-44 have been rejected 
under 35 U.S.C 102(e) as anticipated by Ueda et al. ("Ueda"; US 
2004/0190459). The Office Action states that Ueda discloses all the 
limitations of claims 1, 12, 22, 32, 41, and 43 in paragraphs [0009-0010, 
0074-0075, and 0122-0123]. 

The Office Action states that Ueda discloses the limitation of 
an index field in an RTP packet header, citing paragraphs [0003], [0009- 
0010], [0074-0075], and Fig. 25. The Office Action states that Ueda 
discloses the limitation of using the index to point to a PCR MPEG2TS 
randomly positioned in the RTP packet payload, citing 504, Fig. 25, 
[0095]. The Office Action states that the storage area is maintained by 
using indexes (Fig. 4, [0095], and [0099]. 

Paragraphs [0009-0010] in Ueda disclose a conventional 
process where MPEP2 TS packets are carried in an RTP packet. The 
process generates a timestamp from the PCR field, which is included in 
the RTP header. These paragraphs do not describe any linkage 
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mechanism established between a PGR timestamp and an RTP 
timestamp. With respect to independent claims 1 and 12, Ueda's 
paragraphs do not disclose an index carried in an RTP packet header, an 
index that points to a PCR MPEG2TS randomly positioned in the RTP 
packet payload, or the linking of a timestamp with the PCR MPEG2TS as 
a result of the index pointing. With respect to independent claims 22 and 
32, Ueda's paragraphs do not disclose a timestamp packet index carried in 
an RTP packet header, a timestamp packet index that points to a PCR 
MPEG2TS randomly positioned in the RTP packet payload, or the linking 
of a timestamp with the PCR MPEG2TS as a result of the timestamp 
packet index pointing. With respect to independent claims 41 and 43, 
Ueda's paragraphs do not disclose accessing a local timestamp carried in 
the RTP packet payload that is linked to the PCR MPEG2TS to eliminate 
transmission delay jitter. 

Ueda's paragraphs [0074 and 0075] disclose a transmission 
process that generates an RTP packet by adding an RTP header to a TS 
(Fig. 1). The RTP header includes an RTP timestamp and RTP sequence 
number. A reception process depacketizes the payload from the RTP 
packet. A timer 130 is used to measure the arrival times and arrival time 
jitter is computed. With respect to claims 1, 12, 22, and 32, these 
paragraphs do not disclose an (timestamp packet) index carried in an RTP 
packet header, an (timestamp packet) index that points to a PCR 
MPEG2TS randomly positioned in the RTP packet payload, or the linking 
of a timestamp with the PCR MPEG2TS as a result of the (timestamp 
packet) index pointing. Neither do these paragraphs disclose accessing a 
local timestamp carried in the RTP packet payload that is linked to the 
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PCR MPEG2TS to eliminate transmission delay jitter. With respect to 
claims 41 and 43, these paragraphs do not disclose an MPEG2TS delay * 
compensation data structure that is carried in an RTF packet payload and 
that includes a local timestamp and a corresponding PCR MPEG2TS, 
Likewise, these paragraphs do not disclose linking the local timestamp to 
the PCR MPEG2TS. 

Paragraph [0099] discloses a management means that stores 
a payload in a buffer, and records the start address, data length, and RTP 
header. An index maintains a correspondence between the stored 
information and an RTP sequence number. The sequence numbers permit 
the stored packets to be arranged in the correct order, in the event they 
are received at incorrect times due to the effect of the network. 
Paragraphs [0095] and [0099] do not disclose an (timestamp packet) index 
carried in an RTP packet header, an (timestamp packet) index that points 
to a PCR MPEG2TS randomly positioned in the RTP packet payload, or 
the linking of a timestamp with the PCR MPEG2TS as a result of the 
(timestamp packet) index pointing. Neither do these paragraphs disclose 
accessing a local timestamp carried in the RTP packet payload that is 
linked to the PCR MPEG2TS to eliminate transmission delay jitter. 

Paragraph [0095] describes a storage area for storing 
information concerning RTP packets, which is managed by an index. The 
information stored includes headers, start addresses, and data lengths. 
The Applicant notes that Ueda does not disclose a PCR MPEG2TS stored 
in the storage area. The Response to Arguments Section (page 11) 
states that Ueda discloses accessing an index field in the header, and 
using the index field to point to a PCR MPEG2TS randomly positioned in 
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the RTP packet payload, citing paragraph [0095]] and Fig. 25 - 504. 
Paragraph 0095 states: 

[0095] The queue 122 has a plurality of storage 
areas each used for storing information on an RTP packet. 
The storage areas are managed by using indexes. The 
information on an RTP packet includes the header of the 
RTP packet, the start address of the payload included in the 
RTP packet and the data length of the RTP packet. As 
described above, the payload is stored in the reception buffer 
121. 

The above-cited paragraph does not state that there is an 
(timestamp packet) index field stored in an RTP header, as cited in the 
claimed invention, The above-cited paragraph does not state that the 
disclosed index is carried as a (timestamp packet) index in an RTP packet 
header, as cited in the claimed invention. Alternately stated, the 
management of a storage area by an index does not mean that the index is 
carried in a packet header. And even if Ueda's index was carried in a 
header, there is no language or drawings in the Ueda reference stating 
that Ueda's index points to a PGR MPEG2TS, or that the index points to a 
randomly positioned PCR MPEG2TS. 

Ueda's Fig. 25 is a diagram showing the configuration of RTP 
process unit 500 employed in a conventional communications apparatus 
[0008]. Reference designator 504 is described as PCR registers. Packet 
synthesis unit 506 generates RTP a timestamp from the value of the PCR 
filed stored in the PCR register 504 [0010]. These paragraphs do not 
disclose an (timestamp packet) index carried in an RTP packet header, an 
(timestamp packet) index that points to a PCR MPEG2TS randomly 
positioned in the RTP packet payload, or the linking of a timestamp with 
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the PGR MPEG2TS as a result of the (timestamp packet) index pointing. 

Paragraphs [0008-0010] state; 

[0008] Next, the RTP process unit 500 is 
explained in detail. FIG. 25 is a diagram showing the 
configuration of the RTP process unit 500 employed in the 
conventional communication apparatus. 

[0009] In this case, in accordance with the RFC 2250, an RTP 
packet having an MPEG-2 transport stream (referred to 
hereafter simply as an MPEG2-TS) as a payload is required 
to include an RTP timestamp field in the RTP header as a 
field having a value synchronized to the data stored in a PGR 
(Program Clock Reference) field of a TS packet, which is 
enclosed in the RTP packet as a portion of the RTP payload. 

[0010] In the RTP process unit 500, when a TS packet 
generated by an MPEG-2 encoder 311 is supplied to an 
encoder interface (I/F) 312, the TS packet is passed on to a 
TS header checker 502, which checks the header of the TS 
packet to detect a PCR field. The TS header checker 502 
stores the detected PCR field in PCR registers 504 and 
temporarily stores the TS packet in a TS buffer 505. A packet 
transmission control unit 503 manages information such as 
the number of input TS packets. As conditions for a packet 
transmission are all satisfied, the packet transmission 
control unit 503 issues a request for a transmission of an 
RTP packet to a packet synthesis unit 506. At this request, 
the packet synthesis unit 506 generates a timestamp from 
the value of the PCR field stored in the PCR registers 504. 
The packet synthesis unit 506 also generates the RTP packet 
including an RTP payload and an RTP header. The RTP 
payload includes the TS packets stored in the TS buffer 505 
and the RTP header includes the generated timestamp in the 
RTP timestamp field of the RTP header. 



The Applicant's claims are narrowly tailored to recite that 
the PCR MPEG2TS can be randomly positioned in an RTP packet, if a 
(timestamp packet) index is embedded in the packet header. The 
(timestamp packet) index is used to find the position of the PCR 
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MPEG2TS. The Applicant has analyzed the cited sections in detail, 
above, and conclusively shown that the cited sections do not disclose the 
claimed limitations. Ueda's Fig. 25 ([0008-0010]) and [0095] cannot be 
used to support the assertions made by the Examiner. Without support 
for the Examiner's assertions, a prima facie case has not been made in 
support of the rejection. 

Thus, none of the above-cited sections from Ueda describe a 
process that accesses an index field in a RTP packet header, or that uses 
the index to locate a PCR MPEG2TS randomly positioned in the RTP 
payload (claims 1 and 22). Neither does Ueda describe a process that 
encapsulates an index field to a RTP packet header for use in locating a 
PCR MPEG2TS that is randomly positioned in the RTP payload (claims 
12 and 32). None of the above-cited paragraphs disclose an MPEG2TS 
delay compensation data structure that is earned in an RTP packet 
payload and that includes a local timestamp linked to a corresponding 
PCR MPEG2TS for eliminating transmission delay jitter (claims 41 and 
43). 

"A claim is anticipated only if each and every element as set 
forth in the claim is found, either expressly or inherently described, in a 
single prior art reference." Verdegaal Bros. v. Union Oil of California, 814 
F.2d 628, 631, 2 USPQ2d 1051, 1053 (Fed. Cir. 1987). 

Ueda does disclose every limitation of claims 1, 12, 22, 32, 41, 
and 43. Since Ueda does not disclose every limitation of the claimed 
invention, he cannot anticipate these claims. 
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CLAIMS 3-4. 7-8. 11, 14-15. 18-19. 24-25. 28. 31, 34-35. 38. 42. and 44 

Claims 3-4, 7-8, and 11, dependent from claim 1, claims 14- 
15 and 18-19, dependent from claim 12, claims 24-25, 28, and 31, 
dependent from claim 22, claims 34-35 and 38, dependent from claim 32, 
claim 42, dependent from claim 41, and claim 44, dependent from claim 
43, enjoy the same distinctions from the cited prior art as the underlying 
independent claims. Therefore, Ueda cannot anticipate these dependent 
claims. 

2. The rejection of claims 2, 13, 23, and 33 under 35 
U.S.C. 103(a) as unpatentable with respect to Ueda in view of Ando 
et al ("Ando"; US 7,274,863). 

CLAIMS 2. 13. 23. AND 33 

In Section 24 of the Office Action, claims 2, 13, 23, and 33 
have been rejected under 35 U.S.C. 103(a) with respect to Ueda in view of 
Ando et al. ("Ando"; US 7,274,863). The Office Action acknowledges that 
Ueda fails to disclose a timestamp resolution of 500 ns, but that Ando 
discloses this feature, and that it would have been obvious to modify Ueda 
to include the teachings of Ando to synchronize the timestamp with the 
value stored in the TS packet. 

The Ando reference is cited to introduce, as Background Art, 
the fact that the MPEG2 protocols specify a PCR arrival time of ± 500 ns. 
The Applicant can only find the term "synchronously" used twice in the 
Ando reference, again in the Background Art Section, in the explanation 
of conventional art time delay (col. 2, In. 17-26). Note: Ando does not 
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describe a means of improving synchronization or improving jitter better 
than the 500 ns standard. 



An invention is unpatentable if the differences between it 
and the prior art would have been obvious at the time of the invention. As 
stated in MPEP § 2143, the KSR International Co. v Teleflex Inc. decision 
(82 USPQ2d 1385, 1395-1397, 2007) suggests 7 exemplary rationales to 
support a conclusion of obviousness, which include: 

A) Combining prior art elements according to known 
methods to yield predictable results; 

B) Simple substitution of one known element for another to 
obtain predictable results; 

C) Use of known technique to improve similar devices 
(methods, or products) in the same way; 

D) Applying a known technique to a known device (method, 
or product) ready for improvement to yield predictable results; 

E) "Obvious to try" - choosing from a finite number of 
identified, predictable solutions, with a reasonable expectation of success; 

F) Known work in one field of endeavor may prompt 
variations of it for use in either the same field or a different one based on 
design incentives or other market forces if the variations are predictable 
to one of ordinary skill in the art; 

G) Some teaching, suggestion, or motivation in prior art 
would have lead one of ordinary skill to modify the prior art reference or 
the combine prior art references teachings to arrive at the claimed 
invention. 
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The Office Action states that modifications to Ueda would 
have been obvious to one of ordinary skill in the art in light of Ando. This 
rejection appears to be most closely grounded in the G) rationale - Some 
teaching, suggestion, or motivation in prior art would have lead one of 
ordinary skill to modify the prior art reference or the combine prior art 
references teachings to arrive at the claimed invention. 

With respect to this rationale, MPEP 2143 (G) states that the 
rejection must articulate the following criteria to resolve the Graham 
factual analysis: 

(1) a finding that there was some teaching, suggestion or 
motivation, either in the references themselves or in the knowledge 
generally available to one of ordinary skill in the art, to modify the 
reference or combine reference teachings; 

(2) a finding that there was a reasonable expectation of 

success; and 

(3) whatever additional findings based on the Graham 
factual inquiries may be necessary, in view of the facts of the case under 
consideration, to explain a conclusion of obviousness. 

With respect to the first Graham factual analysis criteria, 
the obviousness rejection is based upon the assumption that that Ueda 
discloses all the limitations of the base claims 1, 12, 22, and 32. However, 
even if timestamp resolution specification of 500 ns is added to Ueda, the 
combination of references fails to disclose the limitations of accessing an 
(timestamp packet) index in an RTP header, using the (timestamp packet) 
index to locate a PCR MPEG2TS that is randomly positioned in the RTP 
payload, or linking a timestamp with the PCR MPEG2TS to eliminate 
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jitter, as recited in Applicant's claims 1 and 22. Neither does the 
combination of references describe a process that encapsulates an 
(timestamp packet) index field to a RTP packet header for use in locating 
a PGR MPEG2TS that is randomly positioned in the RTP payload, as 
recited in claims 12 and 32. 

Further, the motivation of "synchronization" does not suggest 
modifications to Ueda that would make the Applicant's claim limitations 
obvious, based on either the Ando reference, or what was well known at 
the time. The 500 ns PCR arrival time jitter is defined in the protocol, 
and Ueda would have been unable to practice his invention without 
already being compliant to this specification. Therefore, there appears to 
be no motivation to modify Ueda based upon the rationale of 
synchronization. Unless it can be shown that Ando suggests modifications 
to Ueda that include a (timestamp packet) index, embedded in a header 
and pointing to a randomly positioned PCR MPEG2TS, then Ando (or 
synchronization) cannot be said to suggest modifications that make the 
claimed invention obvious. Therefore, the combination of references 
neither explicitly discloses all the claim limitations, nor suggests 
modification to Ueda that would make all the limitations obvious. 

The Response to Arguments Section of the Office Action 
(page 12) states that the Applicant's arguments have been directed to the 
references individually, citing In re Keller. The Applicant respectfully 
disagrees. The Applicant has discussed the combination of the 500 ns 
jitter specification (Ando) with Ueda. However, since Ueda would have 
already been compliant with this specification in order to practice his 
invention, it is difficult to see how the 500 ns specification suggests any 
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modifications to Ueda. Also as noted above, the combination of references 
does not comprise all the limitation recited in the claimed invention. 

The obviousness rejection may also be supported by what 
was well known at the time of the invention. In that case however, the 
obviousness rejection must provide evidence that such a modification 
would have been obvious to one with skill in the art based upon what was 
well known at the time of the invention. "(A)nalysis [of whether the 
subject matter of a claim would have been obvious] need not seek out 
precise teachings directed to the specific subject matter of the challenged 
claim, for a court can take account of the inferences and creative steps 
that a person of ordinary skill in the art would employ." KSR InVl Co. u. 
Teleflex, Inc., 127 S. Ct. 1727, 1740-41, 82 USPQ2d 1385, 1396 (2007). 
However, if the prima facie rejection is supported by what was known by a 
person of ordinary skill in the art then additional evidence should have 
been provided. Notable, when the source or motivation is not from the 
prior art references, "the evidence" of motive will likely consist of an 
explanation or a well-known principle or problem-solving strategy to be 
applied". DyStar, 464 F.3d at 1366, 80 USPQ2d at 1649. 

The only principle or problem-solving strategy mentioned in 
the Office Action is "synchronization". The Office Action does not supply 
evidence that it was well known at the time of the invention to access an 
(timestamp packet) index in an RTP header, use the (timestamp packet) 
index to locate a PCR MPEG2TS that is randomly positioned in the RTP 
payload, or link a timestamp with the PCR MPEG2TS to eliminate jitter. 

A prima facie analysis of motivation is especially critical in 
the instant rejection, since the rejection is predicated on limitations that 
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are not explicitly disclosed in the prior art references. The claimed 
invention can only be obvious if an artisan makes substantial 
modifications to Ueda. However, there is nothing in the Ando reference 
that suggests a modification. Further, no evidence has been provided that 
such a modification would have been obvious based upon well known 
principles. 

With respect to the second analysis criteria needed to 
support the G) obviousness rationale, even if a practitioner were given the 
Ueda and Ando references as a foundation, no evidence has been provided 
to show that there is a reasonable expectation of success in the claimed 
invention. That is, there can be no reasonable expectation of success if the 
references, and what was known by artisan at the time of the invention, 
do not teach all the limitations of the claimed invention. 

In summary, the Applicant respectfully submits that a prima 
facie case of obvious has not been supported since the combination of 
Ueda and Ando does not explicitly disclose every limitation of claims 1, 12, 
22, and 32. Claims 2, 13, 23, and 33 are respectively dependent from 
these independent claims, and includes the same limitations. Neither has 
a case been supported that Ueda can be modified to supply the missing 
limitations in view of Ando, or what was well known by a person of skill at 
the time of the invention. 
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SUMMARY AND CONCLUSION 

It is submitted that for the reasons pointed out above, the 
claims in the present application clearly and patentably distinguish over 
the cited references. Accordingly, the Examiner should be reversed and 
ordered to pass the case to issue. 



Respectfully submitted, 



Date: 6/8/2009 /Gerald Maliszewski/ 

Gerald Maliszewski 
Registration No. 38,054 

Customer Number 55,286 

P.O. Box 270829 

San Diego, CA 92198-2829 

Telephone: (858) 451-9950 

Facsimile: (858) 451-9869 

gerry@ipatentit.net 
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CLAIMS APPENDIX 
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IN THE CLAIMS: 



1. (previously presented) A method for receiving an 
MPEG2 transport stream (TS) in a real-time protocol (RTP)/user 
datagram protocol (UDP)/Internet protocol (IP) packet, the method 
comprising: 

receiving an IP packet via an IP network, having a variable 
transmission delay; 

accessing a timestamp carried in a RTP packet; 

accessing an index field in the RTP packet header; 

linking the timestamp with a program clock reference (PCR) 
MPEG2TS carried in the RTP packet payload by using the index to point 
to a PCR MPEG2TS randomly positioned in the RTP packet payload; and, 

using the timestamp to eliminate variable transmission 
delay jitter, associated with the PCR MPEG2TS. 

2. (original) The method of claim 1 wherein accessing 
the timestamp carried in the RTP packet includes accessing a timestamp 
having a resolution of greater than 500 nanoseconds (ns); and, 

wherein using the timestamp to eliminate variable 
transmission delay jitter, associated with the PCR MPEG2TS, includes 
reducing the jitter to less than 500 ns. 

3. (original) The method of claim 1 wherein accessing 
a timestamp carried in the RTP packet includes accessing a RTP 
timestamp carried in a RTP packet header. 
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4. (original) The method of claim 3 wherein linking 
the timestamp with a PCR MPEG2TS carried in the RTP packet payload 
includes linking the RTP timestamp with a solitary PCR MPEG2TS 
carried in the RTP packet payload. 

5-6. canceled 

7. (previously presented) The method of claim 1 
wherein accessing an index field in the RTP packet header includes 
accessing a timestamp packet index field; and, 

wherein linking the timestamp with a PCR MPEG2TS 
carried in the RTP packet payload includes using the timestamp packet 
index to link an RTP timestamp to a PCR MPEG2TS randomly positioned 
in the RTP packet payload. 

8. (previously presented) The method of claim 1 
wherein accessing an index field in the RTP packet header includes 
accessing a PCR MPEG2TS index field; 

wherein accessing a timestamp carried in the RTP packet 
includes accessing a PCR MPEG2TS timestamp earned in a RTP packet 
header; and, 

wherein linking the timestamp with a PCR MPEG2TS 
carried in the RTP packet payload includes using the PCR MPEG2TS 
index to point to a PCR MPEG2TS randomly positioned in the RTP packet 
payload. 

9-10. canceled 
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11. (original) The method of claim 1 wherein using the 
timestamp to eliminate variable transmission delay jitter, associated with 
the PCR MPEG2TS, includes using the timestamp to determine the target 
transmission time of the PCR MPEG2TS. 

12. (previously presented) A method for transmitting 
an MPEG2 transport stream (TS) in a real-time protocol (RTP)/user 
datagram protocol (UDP)/Internet protocol (IP) packet, the method 
comprising: 

encapsulating a program clock reference (PCR) MPEG2TS in 
the RTP packet payload; 

encapsulating a timestamp randomly positioned in a RTP 
packet payload, referencing the PCR MPEG2TS target transmission time; 

encapsulating the RTP packet in an IP packet; 

encapsulating an index in the RTP packet header pointing to 
the position of the MPEG2TS in the RTP packet payload; and, 

transmitting the IP packet via an IP network. 

13. (original) The method of claim 12 wherein 
encapsulating a timestamp in a RTP packet, referencing the PCR 
MPEG2TS, includes encapsulating a timestamp having a resolution of 
greater than 500 nanoseconds (ns). 

14. (original) The method of claim 12 wherein 
encapsulating a timestamp in a RTP packet includes encapsulating an 
RTP timestamp in the RTP packet header. 



SLAl535_appeal brief.doc 



26 



15. (original) The method of claim 14 wherein 
encapsulating a PCR MPEG2TS in the RTP packet payload includes 
encapsulating a solitary PCR MPEG2TS in the RTP packet payload. 

16-17. canceled 

18. (previously presented) The method of claim 12 
wherein encapsulating a timestamp in a RTP packet includes 
encapsulating an RTP timestamp in the RTP packet header; and, 

wherein encapsulating an index in the RTP packet header 
includes encapsulating a timestamp packet index in the RTP packet 
header. 

19. (previously presented) The method of claim 12 
wherein encapsulating a timestamp in the RTP packet includes 
encapsulating a PCR MPEG2TS timestamp; and, 

wherein encapsulating an index in the RTP packet header 
includes encapsulating a PCR MPEG2TS index field in the RTP packet 
header. 

20-21. canceled 

22. (previously presented) A system for receiving an 
MPEG2 transport stream (TS) in a real-time protocol (RTP)/user 
datagram protocol (UDP)/Internet protocol (IP) packet, the system 
comprising: 
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a decoder having an IP network interface to receive an IP 
packet via an IP network, having a variable transmission delay, and an 
interface to supply a RTP packet; 

a buffer having an interface to accept the RTP packet, the 
buffer accessing a timestarap packet index field carried in a RTP packet 
header and uses the timestamp packet index to point to a PCR MPEG2TS 
randomly positioned in the RTP packet payload, linking the timestamp 
with a program clock reference (PCR) MPEG2TS carried in the RTP 
packet payload, and using the timestamp to eliminate variable 
transmission delay jitter, the buffer having an interface to supply the PCR 
MPEG2TS with a constant delay; and, 

a system clock having an interface to receive the PCR 
MPEG2TS with the constant delay and to provide a synchronized system 
time. 

23. (previously presented) The system of claim 22 
wherein the buffer accesses a timestamp having a resolution of greater 
than 500 nanoseconds (ns) and supplies a PCR MPEG2TS with a jitter of 
less than 500 ns. 

24. (previously presented) The system of claim 22 
wherein the buffer accesses a RTP timestamp carried in a RTP packet 
header. 

25. (previously presented) The system of claim 24 
wherein the buffer links the RTP timestamp with a solitary PCR 
MPEG2TS carried in the RTP packet payload. 
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26-27. canceled 

28. (previously presented) The system of claim 22 
wherein the buffer accesses a PCR MPEG2TS index field in the RTP 
packet header, accesses a PCR MPEG2TS timestamp carried in a RTP 
packet header, uses the PCR MPEG2TS index to point to a PCR 
MPEG2TS randomly positioned in the RTP packet payload, and uses the 
PCR MPEG2TS timestamp to eliminate variable transmission delay jitter. 

29-30. canceled 

31. (previously presented) The method of claim 22 
wherein the buffer uses the timestamp to determine the target 
transmission time of the PCR MPEG2TS. 

32. (previously presented) A system for transmitting an 
MPEG2 transport stream (TS) in a real-time protocol (RTP)/user 
datagram protocol (UDP)/Internet protocol (IP) packet, the system 
comprising: 

a system clock having an interface to supply a program clock 
reference (PCR) MPEG2TS; 

a buffer having an interface to accept the PCR MPEG2TS, 
the buffer randomly positioning the PCR MPEG2TS in a RTP packet 
payload, encapsulating a timestamp packet index in the RTP packet 
header referencing the PCR MPEG2TS target transmission time, 
encapsulating the RTP packet in an IP packet, the timestamp packet 
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index pointing to the position of the MPEG2TS in the RTP packet 
payload, and supplying the IP packet at an interface; and, 

a system coder having an interface to accept the IP packet 
and an interface to transmit the IP packet via an IP network. 



33. (previously presented) The system of claim 32 
wherein the buffer encapsulates a timestamp having a resolution of 
greater than 500 nanoseconds (ns). 

34. (previously presented) The system of claim 32 
wherein the buffer encapsulates an RTP timestamp in the RTP packet 
header. 

35. (previously presented) The system of claim 34 
wherein the buffer encapsulates a solitary PGR MPEG2TS in the RTP 
packet payload. 

36-37. canceled 

38. (previously presented) The system of claim 32 
wherein the buffer encapsulates a PCR MPEG2TS randomly positioned in 
the RTP packet payload, encapsulates a PCR MPEG2TS timestamp, and 
encapsulates a PCR MPEG2TS index field in the RTP packet header 
pointing to the position of the MPEG2TS in the RTP packet payload. 

39-40. canceled 
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41. (previously presented) A method for receiving an 
MPEG2 transport stream (TS) in a real-time protocol (RTP)/user 
datagram protocol (UDP)/Internet protocol (IP) packet, the method 
comprising: 

receiving an IP packet via an IP network, having a variable 
transmission delay; 

accessing a local timestarnp field in an MPEG2TS delay 
compensation data structure, where the MPEG2TS delay compensation 
data structure is carried in the RTP packet payload and includes the local 
timestarnp and a corresponding PCR MPEG2TS; 

linking the timestarnp with a program clock reference (PCR) 
MPEG2TS carried in the RTP packet payload; 

using the timestarnp to eliminate variable transmission 
delay jitter, associated with the PCR MPEG2TS; and, 

wherein linking the timestarnp with a PCR MPEG2TS 
carried in the RTP packet includes linking the local timestarnp to the 
corresponding PCR MPEG2TS in the MPEG2TS delay compensation data 
structure. 

42. (previously presented) The method of claim 41 
wherein accessing a local timestarnp field in an MPEG2TS delay 
compensation data structure includes accessing a local timestarnp field in 
each of a plurality of MPEG2TS delay compensation data structures 
carried in the RTP packet payload, where the MPEG2TS delay 
compensation data structures include an MPEG2TS selected from the 
group including PCR and non-PCR MPEG2TSs; 
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wherein linking the timestarap with a PCR MPEG2TS 
carried in the RTP packet payload additionally includes linking local 
timestamps with corresponding non-PCR MPEG2TSs; and, 

wherein using the timestamp to eliminate variable 
transmission delay jitter, associated with the PCR MPEG2TS, 
additionally includes using the local timestamps to eliminate jitter 
associated with corresponding non-PCR MPEG2TSs. 

43. (previously presented) A method for transmitting 
an MPEG2 transport stream (TS) in a real-time protocol (RTP)/user 
datagram protocol (UDP)/Internet protocol (IP) packet, the method 
comprising: 

encapsulating a program clock reference (PCR) MPEG2TS in 
an MPEG2TS delay compensation structure, carried in the RTP packet 
payload; 

encapsulating a timestamp in a RTP packet, referencing the 
PCR MPEG2TS target transmission time; 

encapsulating the RTP packet in an IP packet; 

transmitting the IP packet via an IP network; and, 

wherein encapsulating a timestamp in the RTP packet 
includes encapsulating a local timestamp in the MPEG2TS delay 
compensation data structure, referencing the co-encapsulated PCR 
MPEG2TS. 

44. (previously presented) The method of claim 43 
wherein encapsulating the PCR MPEG2TS in an MPEG2TS delay 
compensation structure includes encapsulating a plurality of MPEG2TSs, 
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selected from the group including PCR MPEG2TSs and a non-PCR 
MPEG2TSs, in a corresponding plurality of MPEG2TS delay 
compensation structures; and, 

wherein encapsulating a local timestamp field in the 
MPEG2TS delay compensation data structure includes encapsulating a 
local timestamp field in each MPEG2TS delay compensation structure, 
referencing a co-encapsulated MPEG2TS. 
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EVIDENCE APPENDIX 
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RELATED PROCEEDINGS APPEND DC 
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